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ABSTRACT 


This  paper  advocates  an  approach  (called  the  axiomatic  method) 
to  reduce  the  costs  of  constructing  an  information  system. 
Further,  we  contrast  the  applicability  of  the  axiomatic  method  to 
the  more  traditional  approach  of  enumerating  alternatives  (the 
algorithmic  method)  in  constructing  an  information  system. 

We  delineate  the  steps  involved  in  building  an  information 
system,  present  a  set  of  pilot  axioms,  and  offer  some  derivative 
theorems.  We  then  apply  these  axioms  and  theorems  to  each  phase 
(specification,  design,  implementation  and  maintenance)  of  the 
information  system  life  cycle,  and  confirm  a  number  of  empirical 
results  other  information  system  builders  have  observed. 
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1 .  INTRODUCTION 

Our  discussion  of  PRODUCTIVITY  pertains  to  the  reduction  in 
time  and  cost  involved  in  all  four  phases  of  building  an 
information  system  (specification,  design,  implementation  and 
maintenance).  We  include  in  the  term  INFORMATION  SYSTEM  any 
computer-based  system  used  to  store,  analyze  and  present 
information.  This  includes  the  spectrum  of  systems  from 
operational  examples  such  as  payroll  accounting  to  decision 
support  systems  for  strategic  planning. 

The  purpose  of  this  paper  is  to  present  a  systematic  method 
for  whittling  down  construction  time  and  cost;  this  is  to  be 
achieved  by  strategically  reducing  the  number  of  alternatives 
that  a  system  builder  must  evaluate  when  constructing  an 
information  system. 

We  use  the  term  INFORMATION  SYSTEM  CONSTRUCTION  to  apply  to 
all  four  phases  of  the  system  life  cycle.  Likewise  the  term 
INFORMATION  SYSTEM  BUILDER  refers  to  the  person(s)  in  charge  of 
these  four  phases. 

1.1  BACKGROUND  ON  AXIOMATICS 

In  some  areas  such  as  manufacturing,  it  has  been  recognized 
that  certain  design  decisions  (e.g.  maintaining  modularity) 
always   appear   to   yield   superior   designs.    This   observation 
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suggests  the  existence  of  basic  natural  principles  which  govern 
the  process.  If  these  principles  or  axioms  can  be  tracked  down 
and  crystallized  for  information  systems,  we  may  establish  a 
scientific  approach  to  design. 

AXIOMS  are  general  truths  immune  to  violations  or 
counter-examples.  They  are  to  be  taken  as  first  principles  and 
are  intrinsically  unprovable. 

THEOREMS  may  be  defined  as  readily  derivable  consequences  of 
axioms,  while  COROLLARIES  are  readily  deducible  results  of  axioms 
and  theorems. 

FUNCTIONAL  REQUIREMENTS  are  the  minimum  set  of  independent 
specifications  that  completely  define  the  tasks.  Examples 
include  the  capacity  of  the  database,  number  of  daily 
transactions,  degree  of  multiprogramming,  level  of  read/write 
security,  and  extent  of  backup  to  allow  complete  reconstruction. 

In  addition  to  functional  requirements,  constraints  are  often 
needed  to  specify  limits  on  byproducts  or  side  effects. 
CONSTRAINTS  are  specifications  that  define  the  boundaries  within 
which  attributes  of  these  side  effects  are  acceptable.  Examples 
include  upper  limits  on  cooling  requirements  or  mean  time  between 
failures,  or  lower  limits  on  the  accuracy  of  numerical  solutions. 

White  and  Booth  [21],  for  example,  recommend  the  inclusion  of 
these  specifications  for  software  design: 

1.  Functional   specifications.    Definition   of   each   data 
element  and  the  control  structure  among  various  tasks. 

2.  Performance  constraints.   Specification  of   each   subtask 
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to   operate   within   its   time   and  space  constraints  and  to 
allow  the  overall  task  to  do  the  same. 

HEURISTICS  are  similar  to  axioms  in  that  they  both  offer 
working  guidelines.  But  a  heuristic  doesn't  carry  the  weight  of 
an  axiom.   Example  heuristics  might  be: 

1.  "If  your  average   accounts   receivable   is   over   $1,000, 
ignore  those  under  $10." 

2.  "For  clarity  and  readability,  keep  subroutines   under   30 
executable  source  statements."  [20] 

These  are  heuristics  because  they  provide  rules  of  thumb  with  no 
claim  to  ALWAYS  yielding  the  best  result.  In  contrast,  axioms  by 
definition  are  always  valid.  Perhaps  the  most  famous  axioms  are 
those  of  Thermodynamics,  such  as  the  First  Law:  "The  total  energy 
of  a  system  is  constant."  (The  two  sample  heuristics  above  may 
be  promoted  to  axioms  if  industrial  or  psychological  case  studies 
were  to  reveal  that  they  always  produce  the  most  profitable  or 
readable  results.) 

1.2   FRAMEWORK  FOR  INFORMATION  SYSTEMS  DEVELOPMENT 

The  phases  involved  in  constructing  an  information  system  may 
be  classified  in  a  variety  of  ways  [14],  In  this  paper,  we  view 
the  development  phases  as: 

1.  Specification 
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a.  functional  requirements 

b.  constraints 

2.  Architectural  design 

a.  hardware 

b.  software 

3.  Implementation 

a.  hardware  selection 

b.  code  generation 

c.  testing 

4.  Maintenance 

These  phases  are  not  intended  to  be  strictly  partitioned.  For 
example,  according  to  one  method  of  software  development,  the 
encoding  and  testing  of  modules  should  proceed  side  by  side. 

In  addition,  a  development  arising  in  one  phase  might 
necessitate  backtracking  to  an  earlier  one.  In  illustration,  a 
program  error  detected  in  testing  may  require  a  regression  to  the 
coding  or  even  the  software  design  stage.  In  fact,  this  reverse 
process  occurs  often  enough  to  prompt  investigation:  Boehm, 
McClean  and  Urfrig  [2]  have  shown  that  the  cost  of  correcting 
errors  at  coding  time  is  about  twice  that  of  changing  it  at  the 
design  stage;  and  finding  it  at  testing  time  costs  about  10 
times  that  during  design. 

2.   ALGORITHMIC  VERSUS  AXIOMATIC  APPROACH 
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2.1   ALGORITHMICS 

The  techniques  for  evaluating  alternative  information  systems 
may  be  subdivided  into  two  basic  types,  algorithmic  and 
axiomatic.  The  axiomatic  method  is  based  on  a  set  of  rules  which 
efficiently  identify  the  global  optimum.  In  contrast,  the 
algorithmic  approach  is  a  procedural  method  for  considering 
alternatives,  and  may  be  subdivided  further  into  two  categories: 
exhaustive  and  rapid  search  methods. 

2.1.1  EXHAUSTIVE   SEARCH 

One  algorithmic  approach — EXHAUSTIVE  SEARCH — enumerates  all 
possible  configurations  and  choices.  The  drawback  with 
exhaustive  search  with  respect  to  information  system  construction 
lies  in  the  myriad  technical  choices  and  the  explosive  number  of 
functional  requirements  demanded  of  new  systems.  To  illustrate, 
consider  the  recent  design  of  an  information  system  at  Microwave 
Associates  of  Burlington,  Massachusetts:  some  design  attributes 
or  dimensions  considered  were  the  choice  of  operating  system, 
size  of  CPU,  type  of  data  representation,  and  selection  of 
programming  language.  Suppose — in  this  fancifully  small 
example — that  there  are  only  10  such  attributes  to  consider,  with 
say  5  choices  per  attribute.  The  result  is  5**10,  or  over  9 
million,  design  possibilities.  It  would  take  more  than  a  few 
weekends  to  evaluate  them  all. 

2.1 .2  RAPID  SEARCH 
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Another  algorithmic  approach  is  RAPID  SEARCH,  in  which  a  set 
of  guidelines  constrain  the  domain  of  evaluation.  One  example  is 
branch  and  bound,  which  seeks  to  discard  entire  branches  of 
inferior  alternatives  in  the  design  tree. 

Another  example  is  stagewise  optimization:  as  each  attribute 
is  optimized,  the  next  attribute  is  evaluated  cc nditionally  under 
the  constraint  that  the  preceding  attribute  chojces  will  prevail. 

Consider  again  the  4  attributes  mentioned.  The  steps  for 
stagewise  optimization  are: 

Step  1.  Identify  all  attributes  and  all  choices  within  each 

attribute.    Optionally,  these  attributes  might  be  ranked  in 

order  of  importance. 

Step  2.  Select  the  best  choice  of  operating  system.   Call  it 

CI.   Suppose  CI  =  VM/370. 

Step  3.  Select  the  size  of  CPU  given  that  CI  holds.   Call  it 

C2.      Say  C2  =  1024K. 

Step  4.  Select  the  data  representation,   given   CI   and   C2 . 

Say  it's  C3  =  relational  data  model. 

Step  5.  Select  the  programming  language  given   CI,   C2,   and 

C3.   Suppose  C4  =  PL/I. 

Then  the  design  with  {CI , C2 , C3 , 04}  will  be  the  stagewise  optimal. 
Suppose  there  are  n  attributes,  with  m  choices  per   attribute. 
Then  the  stagewise  algorithm  requires 

n 

M   =  E   m. 
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evaluations.   In  contrast,  the  exhaustive  search  method  requires 


n 

N  =  n   m 
es  •  , 


evaluations.   The  efficacy  of  the  stagewise  method  for  a   problem 
with  5  choices  in  each  of  10  dimensions  is 

n 

N     ."-  m.             10         c 
e^s  ^  1=1   '   -  b  ^  2  *  10 

N     "  m.     5  *  10 
SW     T.         1 

i-1 

In  the  class  of  rapid  search  methods,  only  a  few 
well-specified  techniques  (e.g.  branch  and  bound)  can  lay  claim 
to  solution  algorithms  that  yield  the  global  optimum.  Usually 
the  drawback  of  rapid  search  is  its  lack  of  guarantee  of 
producing  the  global  optimum:  the  union  of  optimized  subproblems 
does  not  necessarily  yield  a  global  optimum  unless  the  components 
are  mutually  independent. 

2.2   AXIOMATICS 

The  question  now  arises:  Does  there  exist  a  set  of  general 
principles  which  always  provides  rules  for  eliminating  large 
subsets  of  design  configurations?  The  AXIOMATIC  APPROACH  is  an 
attempt  to  specify  those  rules. 
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3.   PRESENTATION  OF  AXIOMS 

3.1   SOME  DEFINITIONS 

We  may  define  a  FEASIBLE  system  configuration  as  one  that 
satisfies  the  functional  requirements  and  constraints. 

Then  PRODUCTIVITY  may  be  defined  in  a  Pareto-optimal  sense 
[8],  with  time  and  monetary  costs  as  attributes  or  dimensions. 
Consider  two  feasible  configurations  A  and  B.  In  this  paper,  we 
say  that  A  is  more  productive  than  B  if  both  the  time  and  cost 
required  to  build  A  are  less  than  that  of  B. 

For  our  purposes,  INFORMATION  may  be  defined  in  a  variety  of 
ways  [9].  The  information  content  involved  in  a  system  design 
might  be  characterized  by  the  number  of  bits  needed  to  encode  or 
fully  describe  the  design.  When  communication  between  modules  is 
involved,  information  might  be  taken  as  defined  by  Shannon  [171: 


E  -  P.-log^  p. 
1 


where  p  is  the  probability  of  transmitting  the  ith  message,   and 
the  summation  occurs  over  all  possible  messages. 

The  concept  of  ENTROPY  may  be  defined  loosely  as  randomness  or 
disorder.  In  the  sense  of  information  theory  or  statistical 
mechanics,  entropy  may  be  defined  as  the  negative  of  information. 
This  relationship  will  be  explored  further  in  the  future. 

3.2   AXIOMS 
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We  propose  the  following  axioms  as  the  set  applicable  to  the 
construction  of  information  systems: 

A1 :   Productivity   increases   when   information   content   is 

minimized. 

A2 :   Entropy   increases   over   time,   or   at   best    remains 

constant. 

A3:   Productivity   increases   when    the    independence    of 

functional  requirements  is  maintained. 

A1  calls  for  a  minimization  of  information  content. 
Intuitively,  we  expect  the  cost  and  complexity  of  a  particular 
implementation  to  rise  with  a  rise  in  the  information  that  must 
be  used  to  define  the  system. 

A2  refers  to  the  viability  of  implemented  systems.  It  implies 
that  randomness  or  disorder  in  a  system  tends  to  increase  over 
time.  Eventually  the  functional  modularity  of  the  system 
deteriorates  to  the  point  where  a  completely  new  information 
system  must  be  built  afresh.  This  concept  is  discussed  further 
in  connection  with  the  theorems  given  below. 

A3  calls  for  a  solution  which  satisfies  the  functional 
requirements  independently.  A  global  optimum  is  difficult  to 
attain  when  a  change  in  one  attribute  triggers  a  change  in 
others:  this  would  require  the  collective  optimization  of  the 
entire  set  of  interacting  components.  In  contrast,  maintaining 
independence    allows   for   modular    optimization    in   which 
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optimization  of  each  component  may  proceed  independently   of  the 

others.    The   more   independent   the   components,  the  better  the 
solution. 

These  axioms  are  adopted  from  those  that  have  been  applied  to 

other   fields.    A2   is   a   restatement   of   the   Second   Law  of 

thermodynamics;  A1  and  A3  have  been   applied   by   Suh,   Bell  and 
Gossard  [18]  to  manufacturing  systems. 

4.   APPLICATION  OF  THE  AXIOMS 


In  this  section  we  describe  how  the  axioms   give   rise   to   a 

number   of   theorems   pertaining  to  various   phases   of   the 

information  system  life  cycle.  We  also  indicate  how  the  theorems 
might  be  proved. 

4.1   PHASE  1:  SPECIFICATION 

The  first   theorem   follows   from   A1 ,   which   calls  for   a 
minimization  of  information: 

T1.1   Productivity  increases  when  the  number   of   functional 
requirements  are  minimized. 

Obviously  the  information  content  incorporated  in  a  system 
specification  can  only  increase  with  an  increase  in  the  number  of 
functional    requirements   and   constraints.    The   resulting 
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complexity  can  then  only  increase  construction  cost.  This 
assertion  is  consistent  also  with  the  behavior  of  manufacturing 
systems  [22]  . 

n,2      PHASE  2:  ARCHITECTURAL  DESIGN 

In  the  following  theorems,  the  terms  "module"  and  "component" 
may  apply  either  to  hardware  or  software  in  the  architectural 
design  phase: 

T2.1    Productivity   increases   with    increased   use    of 

standardized  or  interchangeable  modules. 

T2.2   A  design  should  incorporate  functional  requirements  in 

a  single  module  if   these   requirements   can   be   kept  from 

mutually  interacting. 

T2.3   If  a  design  exhibits  coupled  functional   requirements, 

these  requirements  should  be  segregated  or  decoupled. 

The  first  theorem  (T2.1)  springs  from  A1  ,  which  requires  a 
minimization  of  information.  When  a  standard  module  is  used,  its 
description  or  specification  is  required  only  once.  If  the 
module  is  needed  again,  it  may  be  specified  simply  by  referencing 
the  original  module. 

T2.2  derives  from  A1 ,  since  a  reduction  in  the  number  of 
discrete  modules  minimizes  information  that  would  otherwise  be 
needed  to  specify  how  all  the  original  modules  would  interact. 
However,   as   A3  requires,  the  functional  requirements  must  still 
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be  independent  of  each  other;  if  not,  the  interdependencies  may 
result  in  increased  overall  information  requirements.  This  is 
the  idea  behind  theorem  T2.3. 

The  use  of  T2.3  may  be  illustrated  by  an  example  from  one  of 
the  writers'  personal  experience.  The  setting  involved  the  Pan 
Am  reservation  system  which  was  experiencing  phenomenal  growth. 
The  system  retrieved  data  through  linear  search  methods;  but  the 
increasing  size  of  the  database  led  to  a  corresponding  increase 
in  retrieval  time,  which  in  turn  reduced  the  daily  rate  of 
transactions  processed.  In  this  case,  the  functional 
requirements  pertaining  to  the  size  of  the  database  and  the 
transaction  processing  rate  had  become  coupled. 

A  decoupling  of  these  functional  requirements  was  in  order; 
this  was  accomplished  by  converting  the  method  to  hashing  [5]. 
For  low  record  densities  in  a  hashed  system,  the  accessing  rate 
(hence  the  transaction  processing  rate)  is  largely  independent  of 
the  database  size. 

4.2.1   PARTITIONING  OF  FUNCTIONAL  REQUIREMENTS 

The  complete  independence  of  functional  requirements  is  an 
ideal  to  strive  for,  but  may  be  difficult  to  attain  in  practice. 
As  a  practical  matter,  a  partial  independence  among  subsets  of 
functional  requirements  may  be  better  than  none. 

We  may  invoke  A1  and  A2  to  yield  the  following  theorem: 

T2.4    Functional  requirements  should   be   partitioned   into 
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smaller  groups  with  minimal  interaction  between  groups. 

Consider  a  financial  applications  package,  for  example. 
According  to  this  theorem,  a  change  in  the  credit  check  module 
should  not  disturb  the  billing  module. 

To  optimally  partition  the  functional  requirements  into 
smaller  groups,  it  is  important  to  first  evaluate  the 
relationships  between  those  requirements.  These  functional 
dependencies  may  then  be  represented  by  an  undirected  graph  (See, 
for  example,  Andreu  [1]  and  Huff  [?]).  Wong  [23]  presents  a 
brief  survey  of  existing  graph-decomposition  techniques  and 
offers  a  better  method  for  finding  subgroups  of  independent 
functional  requirements.  His  technique  is  discussed  in  greater 
detail  in  the  Attachment. 

4.3   PHASE  3:  IMPLEMENTATION 

From  axiom  A1  we  also  propose  another  theorem  applicable  to 
Phase  3b  (software  design)  of  the  information  systems  development 
life  cycle: 

T3.1   The  number  of  program  statements  should  be  minimized. 

This  is  consistent  with  the  empirical  observation  that  cost 
increases  disproportionately  with  program  size  [11]: 


Effort   =  Constant  *  (Number  of  instructions)  ' 
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Another  theorem  due  to  A1  is 

T3.2   Productivity  increases  with  the  use  of  a  higher-level 
language. 

Taliaffero  [19]  reports  that  productivity  is  constant  at  2,400 
statements  per  year  whether  a  program  is  written  in  assembler, 
Fortran  or  Cobol.  Nelson  [12]  also  shows  an  increase  in 
productivity  by  a  factor  of  3  or  more  by  using  higher-level 
languages. 

Some  other  consequences  of  A1  are: 

T3.3   A  system  should  be  decomposed   into   smaller  logical 

units. 

T3.4    Separate  subroutines   should   be   designed   for   each 

elementary  task. 

Here,  information  is  minimized  because  the  interaction  among  the 
elements  of  the  system  are  localized  within  each  nodule.  In  this 
situation,  any  interaction  between  modules  i  and  j  are 
accomplished  as  components  in  their  entirety,  without  the  need 
for  one  to  keep  track  of  the  function  of  each  element  within  the 
other  module. 

One  rule  of  thumb  calls  for  a  partitioning  of  functions  into 
modules  until  each  module  includes  no  two  elements  that  might  be 
useful  in  isolation.    Another   rule   claims   that   each   program 
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module  should  be  small  enough  to  fit  on  one  page,  thereby 
allowing  comprehension  at  a  single  glance. 

The  drive  toward  modularity  is  not  costless,  of  course.  Camp 
and  Jensen  [4]  report  that  modularity  results  in  an  extra  20-35% 
overhead  in  memory  and  another  10-15X  excess  in  run  time  over  a 
monolithic  architecture;  but  these  costs  are  small  in  comparison 
with  the  major  savings  in  productivity  during  development  and 
maintenance.  In  fact,  complexity  and  costs  triple  as  module 
size  doubles.  This  may  be  compared  with  the  concensus  opinion 
of  software  analysts,  who  believe  that  doubling  the  module  size 
will  increase  complexity  and  cost  by  50  to  100%.  As  a  result, 
the  recommended  average  module  size  is  3  to  5  times  the  average 
module  overhead.  For  example,  if  the  module  overhead  is  10 
words,  then  the  average  module  size  should  be  30  to  50  words, 
including  the  overhead. 

A1  and  T3 . 1  suggest  this  result: 

T3.5   The  number  of  instructions  coded  is  not  a  measure   of 
productivity. 

Intuitively,  large-scale  systems  will  require  many  program 
instructions.  But  A1  and  T3 . 1  call  for  a  reduction  in  the  number 
of  instructions  generated.  Hence  productivity  cannot  be  measured 
by  total  program  size. 

4.4   PHASE  4:  MAINTENANCE 
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Axiom  A2  suggests  the  following  theorem: 

T4.1   The  usability  of  a  system   decreases   over   time,   and 
will  eventually  vanish. 

Brooks  [3]  maintains  that  all  information  systems  die  eventually. 
This  is  attributed  to  the  inevitable  patches  or  fixes  to  software 
errors,  and  the  resulting  decay  in  the  conceptual  integrity  of 
the  sytem.   The  need  for  fixes  arise  from  a  variety  of  factors. 

a)  Bugs. 

Bugs  in  large  systems  are  remarkably  hardy  creatures. 
According  to  Brooks  [33,  fixing  one  error  will  merely 
introduce  another  with  20  -  50  %  probability. 

Pikul  and  Wojcik  [15]  offer  the  following  model  for 
verminous  attacks.  As  shown  in  the  diagram,  the  rate  of 
bugs  detected  rises  steeply  at  the  outset  of  any  program. 
As  debugging  proceeds  in  earnest,  the  attack  rate  eventually 
peaks,  then  drops.  But  it  rises  once  again,  to  oscillate 
around  a  steady-state  value  within  an  attenuated  envelope. 

A  highly  damped  version  of  this  model  (steep  rise  and 
slow  decay  to  steady-state  value,  without  the  minor 
oscillations)  is  supported  also  by  Ramamoorthy  and  Ho  [16]. 

b)  Changes  in  user  requirements. 

In  practice,  as  users  become  proficient  with  a  particular 
system,  they  begin  to  demand  higher  performance.  They 
change  the  original  functional  requirements  by  stretching  an 
existing   one   or   even   even   adding   new  ones.   An  airline 
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Rate  of 
Software 
Errors 
Detected 


Cumulative  number  of  program  ru-'is 


reservation  system,  for  example,  may  begin  operation  as  a 
simple  passenger  booking  system.  In  due  course  the  system 
is  expanded  to  allow  for  kosher  meals,  flight  scheduling, 
fuel  distribution,  and  other  functions.  The  rate  of 
addition  of  new  code  could  easily  mean  that  the  bugs  are 
proliferating  faster  than  they  are  being  eliminated, 
c)  Changes  due  to  hardware. 

Technological  advances  may  dictate  the  switch  from,   say, 
an   IBM/370   to  a  /3033  for  increased  processing  speed.   Any 
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such  transformation  is  rife  with  conversion  problems. 

5.   RELATIONSHIPS  BETWEEN  THEOREMS 

The  precedence  relationships  among  the  axioms  and  theorems  may 
be  summarized  as  follows,  where  arrows  indicate  the  relationship 
"derived  from": 


p>  T1.1 

->  TP.1 

-^Y2".2 

Qai   ]-— > 

->[_T3.1   — 

— >fT  3  .  5 

L>[_T3.'4 

A2      

-4T01 

r->rT2.3] 


6.  RELATIONSHIP  TO  CREATIVITY 
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A  question  which  might  arise  is,  "What  role  does  creativity 
play  in  building  information  systems?"  Creativity  precedes 
analysis  in  the  construction  of  information  systems;  it  is 
important  in  the  generation  of  alternative  designs,  without  which 
there  can  be  no  comparative  evaluation. 

A  variety  of  methods  are  available  for  stimulating  creativity 
[6].  One  of  these  is  the  trigger  word  method  involving  questions 
about  what  the  design  is  supposed  to  do.  The  checklist  method 
[13]  is  based  on  a  series  of  questions  on  modification,  such  as 
"Magnify?",  "Rearrange?"  or  "Combine?" 

The  morphological  method  [24]  requires  determining  the 
attributes  involved,  listing  them,  and  considering  all  the 
resulting  combinations. 

Brainstorming  refers  to  the  animated  generation  of  ideas  by  a 
heterogeneous  group  of  participants,  some  of  whom  may  be  entirely 
new  to  the  concepts  under  discussion.  The  purpose  is  to  produce 
as  many  ideas  as  possible,  however  unorthodox  they  may  be. 

This  paper,  however,  is  not  intended  to  address  creativity  per 
se.  The  aim  of  axiomatics  is  to  channel  creativity  by  providing 
a  set  of  guidelines.  The  objective  lies  not  in  the  generation  of 
designs,  but  in  the  assignment  of  relative  merit  to  alternative 
configurations. 

7.   CLOSURE 
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This  paper  has  introduced  the  application  of  the  axiomatic 
approach  to  productivity  in  constructing  information  systems.  We 
have  enumerated  three  pilot  axioms,  proposed  a  number  of 
theorems,  and  indicated  how  the  theorems  spring  from  the  axioms 
and  draw  upon  empirical  results  from  the  construction  of 
information  systems. 

We  note  that  axiomatics  is  not  a  methodology  for  generating 
candidate  designs,  but  a  tool  for  use  in  the  decision-making 
process  of  evaluating  them.  Further,  axiomatics  is  not  intended 
to  supplant  algorithmics.  Rather,  they  will  reinforce  each  other 
in  streamlining  the  development  process,  as  illustrated  by  the 
use  of  the  decomposition  algorithms  discussed  in  Section  4.2.1. 

We  hope  that  this  paper  will  start  a  dialogue  within  the 
informations  systems  community,  so  that  we  may  collectively 
generate  the  analytical  and  experimental  results  needed  to  carry 
this  concept  further.  The  axioms  and  theorems  proposed  here  are 
only  a  pilot  set,  and  may  require  changing,  deleting  or  adding  to 
in  the  light  of  experience. 

In  the  future  we  would  like  to  refine  the  axioms  into  a 
compact  set,  to  rephrase  them  in  a  more  quantitative  form  from 
which  to  prove  the  theorems,  and  to  validate  them  through  case 
studies  in  systems  development.  The  successful  development  of 
the  axiomatic  approach  should  open  up  new  avenues  for  increasing 
productivity  in  the  construction  of  information  systems. 


Axiomatics  10/02/81  Page  22 

ACKNOWLEDGEMENTS 


We  gratefully  acknowledge  our  debt  to  those  who  have  written 
before  us,  both  in  information  systems  and  in  the  application  of 
the  axiomatic  method  in  other  fields.  Recognition  is  due  in 
particular  to  Professor  Nam  P.  Suh  and  his  colleagues  at  the  MIT 
Laboratory  for  Manufacturing  and  Productivity,  and  to  those  in 
the  field  of  thermodynamics  who  initially  applied  the  axiomatic 
method  to  the  analysis  of  physical  systems.  We  also  thank  our 
colleagues  at  the  Sloan  School  of  Management —  Tony  Wong,  Jim 
Lattin  and  Mike  Treacy--for  their  thoughtful  comments  and 
suggestions. 


Axiomatics 


10/02/81  Page  23 


ATTACHMENT-  DECOMPOSITION  OF  FUNCTIONAL  REQUIREMENTS 
BY  THE  HIGH-DENSITY  CLUSTERING  METHOD 

A.I  GRAPHICAL  REPRESENTATION  OF  FUNCTIONAL  REQUIREMENTS 

The  first  task  in  partitioning  functional  requirements  is  to 
represent  them  as  nodes  of  a  graph,  and  the  interdependencies 
between  them  as  arc  weights.  In  building  an  information  system, 
some  examples  of  functional  requirements  might  be: 

1.  The  users  will  be  guided  by  menus. 

2.  A  report-writing  facility  will  allow   users  to  develop 
customized  reports. 

3.  Reports  can  be  directed   to  the   line   printer  or   the 
user's  terminal. 

Each  of  these  functional  requirements  may  be  represented 
graphically  as  a  node  in  a  design  graph.  For  each  pair  of 
functional  requirements,  we  can  consider  the  degree  of 
interrelationship  between  the  nodes.  The  extent  of  this 
association  can  be  characterized  as  the  weight  on  the  link  or  arc 
between  the  pair. 

For  convenience  the  weights  are  normalized  between  0  and  1. 
If  two  functional  requirements  are  deemed  to  have  a  weak 
interdependency,  the  system  builder  might  assign  a  link  weight  of 
0.3;  an  average  degree  of  coupling  may  be  represented  by  0.5;  a 
strong  relationship  by  0.8.  If  two  functional  requirements  are 
deemed  independent,  the  link  weight  is  0.0,  and  the  link  itself 
is  eliminated  from  the  design  graph. 
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Returning  to  our  example  above,  the  first  and  second 
functional  requirements  may  be  considered  independent  and 
therefore  assigned  a  link  weight  of  0  (i.e.  no  link  between  the 
two  nodes).  But  the  first  and  third  may  be  viewed  to  have  an 
average  degree  of  interdependency ,  since  the  report  directing 
aids  must  be  made  available  to  the  user.  So  the  link  weight  is 
given  a  value  of  0.5.  In  this  way  the  set  of  functional 
requirements  and  their  interdependencies  may  be  represented 
graphically. 

A. 2   DENSITY  CONTOURS 

This  section  outlines  the  high-density  clustering  method  for 
functional  decomposition  proposed  by  Wong  [233.  Consider  a  graph 
consisting  of  nodes  and  unweighted  arcs.  Intuitively,  two  nodes 
belong  to  the  same  group  or  cluster  if  they  are  linked  to  each 
other  and  to  many  nodes  in  common.  In  the  figure  below,  nodes  k 
and  1  should  belong  in  the  same  cluster,   while   nodes   i   and   j 
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should   be  in  separate  cluster: 
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between  any  two  nodes  i  and  j  is  defined  as: 


ij 


U  "^J 


No.  of  nodes  connected  tc  both  i  and  j  (including  i  and  j 

No.  of  nodes  connected  to  either  i  or  j  or  both  (includii 

i  and  , 


If  two  nodes  are  unlinked,  their  contour  is  defined  to  be  zero. 

The  figure  below  illustrates  the  use  of  this  definition.    For 
example,  the  contour  between  nodes  1  and  2  is  3/5. 

d*  =  2/8 


For  weighted  arcs,  the  corresponding  definition  for   the   density 
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contour    is 


"ij 
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where  W^- •  =  weight  on  the  link  between  nodes  i  and  j;  C  r  set  of 
nodes  connected  to  both  i  and  j  (excluding  i  and  j). 

Now  we  turn  to  the  idea  of  grouping  individual  nodes.  A  HIGH 
DENSITY  CLUSTER  at  level  d*  on  a  graph  G,  is  a  subgraph  S  such 
that  S  is  maximal  among  connected  sets  of  nodes  whose  nodes  are 
connected  by  links  with  density  contour — 'd*.  The  nested  loops 
in  the  preceding  figure  represent  the  density  contours  for  the 
given  graph. 

The  family  of  high-density  clusters  on  a  graph  may  be  shown  to 
form  a  tree.  As  the  density  level  d*  is  decreased,  the  cluster  S 
at  level  d*  expands  smoothly.  This  gradual  expansion  occurs 
until  a  splitting  level  c^  is  reached,  at  which  point  the 
cluster  joins  with  a  previously  disjoint  cluster.  These  two 
clusters,  called  BRANCHING  CLUSTERS,  are  useful  in  suggesting  the 
number  of  subgraphs  in  the  original  graph.  In  the  diagram  above, 
the  splitting  level  is  d*  =  2/8;  the  two  branching  clusters  are 
{1,2,3,4,5}  and  {6,7,8,9,10}. 

A. 3  IDENTIFYING  AND  PARTITIONING  THE  TREE  OF  HIGH-DENSITY 
CLUSTERS 

Consider  a  set  of  N  nodes  with  density  contours   d(i,j).    The 
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algorithm  to  identify  the  tree  of  high-density  clusters  is: 

STEP1.  Let  i  and  j  be  the  pair  of  nodes  with   densest  link. 

Combine  them  to  form  a  cluster  1;  define  the  density  contour 

between  that  cluster  and  any  node  k  by 

d(l,k)  =  max  [d( i, k) ,d( j, k)] 

STEP2.  Repeat  STEP1 ,  treating  1  as  a  node  and  ignoring  i  and 

j.   The  aggregation  of  nodes  continues  until  all   nodes   are 

absorbed  into  a  single  large  cluster. 
The  foregoing  procedure  is  equivalent  to  the  minimum  spanning 
tree  algorithm.  The  drawback  of  this  procedure  is  that  the  tree 
of  clusters  does  not  explicitly  yield  the  optimal  grouping  of 
functional  requirements.  This  last  step  may  be  effected  by  an 
algorithm  given  by  Lattin  [10],  which  identifies  the  optimal 
subgraphs  of  functional  requirements  from  the  tree. 
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